Traditional and Object-Centric Process Mining

Many processes have multiple options for a case ID for the event log.

If you place an order with an online retailer for example, this order can contain multiple items.
These items can be shipped in one or more packages.
Adding to the complexity, a package might not only contain items for exactly one order, but be used for several orders at the same time, like when multiple employees of a company buy things from the same supplier and they are all shipped in the same package.

Traditional process mining requires that for the entire process, all events are related to exactly one type of Case ID.

This often creates a dilemma of deciding which is the correct CaseID - the order to which all events for individual items or packages are then related, or the package, to which all events of the orders and items are then assigned?

Both choices have disadvantages.

In the order CaseID, some loops can pop up for the item events or for the package events (if items from a single order are shipped in multiple packages).
For a package CaseID, on the other hand, there would be no loops, but duplicates of the events - such as placing order (for order 1 and order 2), or picking (order 1 items and order 2 items), etc. since for each package the events of the order have to be shown individually.

These two effects are called:

Convergence - when one event is replicated across different cases, possibly leading to unintentional duplication. This replication of events can cause misleading diagnostics.
Divergence - when there may be multiple instances of the same activity within a single case. Events on a lower entity level may become indistinguishable and seemingly related. For example, the PickItem and PackItem events happen only once per Item and in a fixed sequence (e.g., you pick the item, then pack it), but within a flattened sales order event log these events may appear to happen many times and in a seemingly random order for an individual case.

Apart from these two effects, traditional mining has further disadvantages, such as:

Data extraction and transformation is painful as relations between many objects need to be reconstructed meticulously.
Interactions between single objects are not captured correctly.
Multiple process dimensionality in reality is squeezed into 2D ("flattened") event logs and models.

Object-centric process mining addresses these limitations of traditional process mining by not defining events as being related to a single case. With this approach, events are no longer related to some previously defined CaseID but to the object which caused the event. Thus, in object-centric process mining a CaseID is no longer of one type, but has several types. Let's take the example from above - events caused by packages are related to the PackageID. Events caused by the items belong to the items and the sales orders' events are connected by the sales order's ID. To relate the objects among each other links are established, thus an inter-object analysis can be carried out easily.

This technique brings several advantages, including not only simplified analysis of processes, but also shortened project cycles due to more realistic event log creation:

Far less process variants lead to better readability of the ProcessAnalyzer.
Better visibility and analysis of sub or side processes.
Processes in which objects run in parallel can be better analyzed, since parallel events no longer generate a high number of variants due to flattening.
Easier detection of insights due to less inter-object event mix-up (convergence & divergence)
Facilitated event log creation as object IDs are normally directly connected to their events, while the traditional CaseID needed careful data modeling and transformation.

The main advantages become very clear when comparing the same process shown in the traditional vs. the object-centric approach:

OCPM vs Traditional Analyzer

MEHRWERK mpmX analytics has included the object-centric approach openly available for our customers as of the December 2022 Release. Of course, the traditional approach is still available and recommended in some use cases.

How to activate one or the other approach is closely described in the Data Engineer Guide.
Configurations regarding the OCPM or the traditional ProcessAnalyzer functionality are given in the Business Analyst Guide.
Last but not least, information and instruction for the use of the OCPM or traditional analytic dashboard are given in the Business User Guide.